home *** CD-ROM | disk | FTP | other *** search
/ Libris Britannia 4 / science library(b).zip / science library(b) / DJGPP / GCC257S5.ZIP / src / gcc-257 / readme.dwa < prev    next >
Text File  |  1992-10-05  |  30KB  |  595 lines
  1. Notes on the GNU Implementation of DWARF Debugging Information
  2. --------------------------------------------------------------
  3. Last Updated: Sun Oct  4 10:04:13 PDT 1992 by rfg@netcom.com
  4. -----------------------------------------------------
  5.  
  6. This file describes special and unique aspects of the GNU implementation
  7. of the DWARF debugging information language, as provided in the GNU version
  8. 2.x compiler(s).
  9.  
  10. For general information about the DWARF debugging information language,
  11. you should obtain the DWARF version 1 specification document (and perhaps
  12. also the DWARF version 2 draft specification document) developed by the
  13. UNIX International Programming Languages Special Interest Group.  A copy
  14. of the the DWARF version 1 specification (in PostScript form) may be
  15. obtained either from me <rfg@netcom.com> or from UNIX International.  (See
  16. below.)  The file you are looking at now only describes known deviations
  17. from the UI/PLSIG DWARF version 1 specification, together with those
  18. things which are allowed by the DWARF version 1 specification but which
  19. are known to cause interoperability problems (e.g. with SVR4 SDB).
  20.  
  21. To obtain a copy of the DWARF version 1 specification from UNIX International,
  22. use the following procedure:
  23.  
  24. ---------------------------------------------------------------------------
  25.     Send mail to archive@ui.org containing the following:
  26.  
  27.         path yourname@your.site
  28.         send PUBLIC/dwarf.v1.mm
  29.  
  30.     for the troff source, or
  31.  
  32.         send PUBLIC/dwarf.v1.ps
  33.  
  34.     for the postscript.  If you system supports uncompress and uudecode,
  35.     you can request that the data be compressed by placing the command
  36.     'compress' in the message.
  37.  
  38.     If you have any questions about the archive service, please contact
  39.     Shane P. McCarron, UI Project Manager, <s.mccarron@ui.org>.
  40. ---------------------------------------------------------------------------
  41.  
  42. The generation of DWARF debugging information by the GNU version 2.x C
  43. compiler has now been tested rather extensively for m88k, i386, i860, and
  44. Sparc targets.  The DWARF output of the GNU C compiler appears to inter-
  45. operate well with the standard SVR4 SDB debugger on these kinds of target
  46. systems (but of course, there are no guarantees).
  47.  
  48. DWARF generation for the GNU g++ compiler is still not operable.  This is
  49. due primarily to the many remaining cases where the g++ front end does not
  50. conform to the conventions used in the GNU C front end for representing
  51. various kinds of declarations in the TREE data structure.  It is not clear
  52. at this time how these problems will be addressed.
  53.  
  54. Future plans for the dwarfout.c module of the GNU compiler(s) includes the
  55. addition of full support for GNU FORTRAN.  (This should, in theory, be a
  56. lot simpler to add than adding support for g++... but we'll see.)
  57.  
  58. Many features from the evolving DWARF version 2 (draft) specification have
  59. been adapted to, and used in the GNU implementation of DWARF (version 1).
  60. In most of these cases, a DWARF version 2 (draft) approach is used in place
  61. of (or in addition to) DWARF version 1 stuff simply because it is apparent
  62. that DWARF version 1 is not sufficiently expressive to provide the kinds of
  63. information which may be necessary to support really robust debugging.
  64. In *all* of these cases however, the use of DWARF version 2 (draft) features
  65. should not interfere in any way with the interoperability (of GNU compilers)
  66. with generally available "classic" (pre version 1) DWARF consumer tools
  67. (e.g. SVR4 SDB). Full support for DWARF version 2 should be available
  68. sometime after the DWARF version 2 specification has been finalized.
  69.  
  70. The DWARF generation enhancement for the GNU compiler(s) was initially
  71. donated to the Free Software Foundation by Network Computing Devices.
  72. (Thanks NCD!) Additional development and maintenance of dwarfout.c has
  73. been largely supported (i.e. funded) by Intel Corporation.  (Thanks Intel!)
  74.  
  75. If you have questions or comments about the DWARF generation feature, please
  76. send mail to me <rfg@netcom.com>.  I will be happy to investigate any bugs
  77. reported and I may even provide fixes (but of course, I can make no promises).
  78.  
  79. The DWARF debugging information produced by GCC may deviate in a few minor
  80. (but perhaps significant) respects from the DWARF debugging information
  81. currently produced by other C compilers.  A serious attempt has been made
  82. however to conform to the published specifications, to existing practice,
  83. and to generally accepted norms in the GNU implementation of DWARF.
  84.  
  85. If you are interested in obtaining more information about DWARF or in
  86. participating in the continuing evolution of DWARF within the UI/PLSIG
  87. group, please contact either myself or the UI/PLSIG chairman, Dan Oldman
  88. <oldman@dg-rtp.dg.com>.  The UI/PLSIG welcomes and encourages the
  89. participation of new members who might be interested in discussing debugging
  90. issues in general, and DWARF in particular.  There are no dues and you
  91. DO NOT have to be a UI member in order to join the UI/PLSIG.  The UI/PLSIG
  92. operates an E-mail mailing list and holds regular meeting in various cities.
  93. If you don't have time to participate actively, but would like to be kept
  94. abreast of recent developments, you con join the UI/PLSIG mailing list and
  95. just listen in on our lively discussions.
  96.  
  97.     ** IMPORTANT NOTE **    ** IMPORTANT NOTE **    ** IMPORTANT NOTE **
  98.  
  99. Under normal circumstances, the DWARF information generated by the GNU
  100. compilers (in an assembly language file) is essentially impossible for
  101. a human being to read.  This fact can make it very difficult to debug
  102. certain DWARF-related problems.  In order to overcome this difficulty,
  103. a feature has been added to dwarfout.c (enabled by the -fverbose-asm
  104. option) which causes additional comments to be placed into the assembly
  105. language output file, out to the right-hand side of most bits of DWARF
  106. material.  The comments indicate (far more clearly that the obscure
  107. DWARF hex codes do) what is actually being encoded in DWARF.  Thus, the
  108. -fverbose-asm option can be highly useful for those who must study the
  109. DWARF output from the GNU compilers in detail.
  110.  
  111. ---------
  112.  
  113. (Footnote: Within this file, the term `Debugging Information Entry' will
  114. be abbreviated as `DIE'.)
  115.  
  116.  
  117. Release Notes  (aka known bugs)
  118. -------------------------------
  119.  
  120. In one very obscure case involving dynamically sized arrays, the DWARF
  121. "location information" for such an array may make it appear that the
  122. array has been totally optimized out of existence, when in fact it
  123. *must* actually exist.  (This only happens when you are using *both* -g
  124. *and* -O.)  This is due to aggressive dead store elimination in the
  125. compiler, and to the fact that the DECL_RTL expressions associated with
  126. variables are not always updated to correctly reflect the effects of
  127. GCC's aggressive dead store elimination.
  128.  
  129. -------------------------------
  130.  
  131. When attempting to set a breakpoint at the "start" of a function compiled
  132. with -g1, the debugger currently has no way of knowing exactly where the
  133. end of the prologue code for the function is.  Thus, for most targets,
  134. all the debugger can do is to set the breakpoint at the AT_low_pc address
  135. for the function.  But if you stop there and then try to look at one or
  136. more of the formal parameter values, they may not have been "homed" yet,
  137. so you may get inaccurate answers (or perhaps even addressing errors).
  138.  
  139. Some people may consider this simply a non-feature, but I consider it a
  140. bug, and I hope to provide some some GNU-specific attributes (on function
  141. DIEs) which will specify the address of the end of the prologue and the
  142. address of the beginning of the epilogue in a future release.
  143.  
  144. -------------------------------
  145.  
  146. It is believed at this time that old bugs relating to the AT_bit_offset
  147. values for bit-fields have been fixed.
  148.  
  149. There may still be some very obscure bugs relating to the DWARF description
  150. of type `long long' bit-fields for target machines (e.g. 80x86 machines)
  151. where the alignment of type `long long' data objects is different from
  152. (and less than) the size of a type `long long' data object.
  153.  
  154. Please report any problems with the DWARF description of bit-fields as you
  155. would any other GCC bug.  (Procedures for bug reporting are given in the
  156. GNU C compiler manual.)
  157.  
  158. --------------------------------
  159.  
  160. At this time, GCC does not know how to handle the GNU C "nested functions"
  161. extension.  (See the GCC manual for more info on this extension to ANSI C.)
  162.  
  163. --------------------------------
  164.  
  165. The GNU compilers now represent inline functions (and inlined instances
  166. thereof) in exactly the manner described by the current DWARF version 2
  167. (draft) specification.  The version 1 specification for handling inline
  168. functions (and inlined instances) was known to be brain-damaged (by the
  169. PLSIG) when the version 1 spec was finalized, but it was simply too late
  170. in the cycle to get it removed before the version 1 spec was formally
  171. released to the public (by UI).
  172.  
  173. --------------------------------
  174.  
  175. At this time, GCC does not generate the kind of really precise information
  176. about the exact declared types of entities with signed integral types which
  177. is required by the current DWARF draft specification.
  178.  
  179. Specifically, the current DWARF draft specification seems to require that
  180. the type of an non-unsigned integral bit-field member of a struct or union
  181. type be represented as either a "signed" type or as a "plain" type,
  182. depending upon the the exact set of keywords that were used in the
  183. type specification for the given bit-field member.  It was felt (by the
  184. UI/PLSIG) that this distinction between "plain" and "signed" integral types
  185. could have some significance (in the case of bit-fields) because ANSI C
  186. does not constrain the signedness of a plain bit-field, whereas it does
  187. constrain the signedness of an explicitly "signed" bit-field.  For this
  188. reason, the current DWARF specification calls for compilers to produce
  189. type information (for *all* integral typed entities... not just bit-fields)
  190. which explicitly indicates the signedness of the relevant type to be
  191. "signed" or "plain" or "unsigned".
  192.  
  193. Unfortunately, the GNU DWARF implementation is currently incapable of making
  194. such distinctions.
  195.  
  196. --------------------------------
  197.  
  198.  
  199. Known Interoperability Problems
  200. -------------------------------
  201.  
  202. Although the GNU implementation of DWARF conforms (for the most part) with
  203. the current UI/PLSIG DWARF version 1 specification (with many compatible
  204. version 2 features added in as "vendor specific extensions" just for good
  205. measure) there are a few known cases where GCC's DWARF output can cause
  206. some confusion for "classic" (pre version 1) DWARF consumers such as the
  207. System V Release 4 SDB debugger.  These cases are described in this section.
  208.  
  209. --------------------------------
  210.  
  211. The DWARF version 1 specification includes the fundamental type codes
  212. FT_ext_prec_float, FT_complex, FT_dbl_prec_complex, and FT_ext_prec_complex.
  213. Since GNU C is only a C compiler (and since C doesn't provide any "complex"
  214. data types) the only one of these fundamental type codes which GCC ever
  215. generates is FT_ext_prec_float.  This fundamental type code is generated
  216. by GCC for the `long double' data type.  Unfortunately, due to an apparent
  217. bug in the SVR4 SDB debugger, SDB can become very confused wherever any
  218. attempt is made to print a variable, parameter, or field whose type was
  219. given in terms of FT_ext_prec_float.
  220.  
  221. (Actually, SVR4 SDB fails to understand *any* of the four fundamental type
  222. codes mentioned here.  This will fact will cause additional problems when
  223. there is a GNU FORTRAN front-end.)
  224.  
  225. --------------------------------
  226.  
  227. In general, it appears that SVR4 SDB is not able to effectively ignore
  228. fundamental type codes in the "implementation defined" range.  This can
  229. cause problems when a program being debugged uses the `long long' data
  230. type (or the signed or unsigned varieties thereof) because these types
  231. are not defined by ANSI C, and thus, GCC must use its own private fundamental
  232. type codes (from the implementation-defined range) to represent these types.
  233.  
  234. --------------------------------
  235.  
  236.  
  237. General GNU DWARF extensions
  238. ----------------------------
  239.  
  240. In the current DWARF version 1 specification, no mechanism is specified by
  241. which accurate information about executable code from include files can be
  242. properly (and fully) described.  (The DWARF version 2 specification *does*
  243. specify such a mechanism, but it is about 10 times more complicated than
  244. it needs to be so I'm not terribly anxious to try to implement it right
  245. away.)
  246.  
  247. In the GNU implementation of DWARF version 1, a fully downward-compatible
  248. extension has been implemented which permits the GNU compilers to specify
  249. which executable lines come from which files.  This extension places
  250. additional information (about source file names) in GNU-specific sections
  251. (which should be totally ignored by all non-GNU DWARF consumers) so that
  252. this extended information can be provided (to GNU DWARF consumers) in a way
  253. which is totally transparent (and invisible) to non-GNU DWARF consumers
  254. (e.g. the SVR4 SDB debugger).  The additional information is placed *only*
  255. in specialized GNU-specific sections, where it should never even be seen
  256. by non-GNU DWARF consumers.
  257.  
  258. To understand this GNU DWARF extension, imagine that the sequence of entries
  259. in the .lines section is broken up into several subsections.  Each contiguous
  260. sequence of .line entries which relates to a sequence of lines (or statements)
  261. from one particular file (either a `base' file or an `include' file) could
  262. be called a `line entries chunk' (LEC).
  263.  
  264. For each LEC there is one entry in the .debug_srcinfo section.
  265.  
  266. Each normal entry in the .debug_srcinfo section consists of two 4-byte
  267. words of data as follows:
  268.  
  269.     (1)    The starting address (relative to the entire .line section)
  270.         of the first .line entry in the relevant LEC.
  271.  
  272.     (2)    The starting address (relative to the entire .debug_sfnames
  273.         section) of a NUL terminated string representing the
  274.         relevant filename.  (This filename name be either a
  275.         relative or an absolute filename, depending upon how the
  276.         given source file was located during compilation.)
  277.  
  278. Obviously, each .debug_srcinfo entry allows you to find the relevant filename,
  279. and it also points you to the first .line entry that was generated as a result
  280. of having compiled a given source line from the given source file.
  281.  
  282. Each subsequent .line entry should also be assumed to have been produced
  283. as a result of compiling yet more lines from the same file.  The end of
  284. any given LEC is easily found by looking at the first 4-byte pointer in
  285. the *next* .debug_srcinfo entry.  That next .debug_srcinfo entry points
  286. to a new and different LEC, so the preceding LEC (implicitly) must have
  287. ended with the last .line section entry which occurs at the 2 1/2 words
  288. just before the address given in the first pointer of the new .debug_srcinfo
  289. entry.
  290.  
  291. The following picture may help to clarify this feature.  Let's assume that
  292. `LE' stands for `.line entry'.  Also, assume that `* 'stands for a pointer.
  293.  
  294.  
  295.     .line section       .debug_srcinfo section     .debug_sfnames section
  296.     ----------------------------------------------------------------
  297.  
  298.     LE  <---------------------- *
  299.     LE                * -----------------> "foobar.c" <---
  300.     LE                                |
  301.     LE                                |
  302.     LE  <---------------------- *                    |
  303.     LE                * -----------------> "foobar.h" <|    |
  304.     LE                                 |    |
  305.     LE                                 |    |
  306.     LE  <---------------------- *                     |    |
  307.     LE                * ----------------->  "inner.h"  |    |
  308.     LE                                 |    |
  309.     LE  <---------------------- *                     |    |
  310.     LE                * -------------------------------    |
  311.     LE                                |
  312.     LE                                |
  313.     LE                                |
  314.     LE                                |
  315.     LE  <---------------------- *                    |
  316.     LE                * -----------------------------------
  317.     LE
  318.     LE
  319.     LE
  320.  
  321. In effect, each entry in the .debug_srcinfo section points to *both* a
  322. filename (in the .debug_sfnames section) and to the start of a block of
  323. consecutive LEs (in the .line section).
  324.  
  325. Note that just like in the .line section, there are specialized first and
  326. last entries in the .debug_srcinfo section for each object file.  These
  327. special first and last entries for the .debug_srcinfo section are very
  328. different from the normal .debug_srcinfo section entries.  They provide
  329. additional information which may be helpful to a debugger when it is
  330. interpreting the data in the .debug_srcinfo, .debug_sfnames, and .line
  331. sections.
  332.  
  333. The first entry in the .debug_srcinfo section for each compilation unit
  334. consists of five 4-byte words of data.  The contents of these five words
  335. should be interpreted (by debuggers) as follows:
  336.  
  337.     (1)    The starting address (relative to the entire .line section)
  338.         of the .line section for this compilation unit.
  339.  
  340.     (2)    The starting address (relative to the entire .debug_sfnames
  341.         section) of the .debug_sfnames section for this compilation
  342.         unit.
  343.  
  344.     (3)    The starting address (in the execution virtual address space)
  345.         of the .text section for this compilation unit.
  346.  
  347.     (4)    The ending address plus one (in the execution virtual address
  348.         space) of the .text section for this compilation unit.
  349.  
  350.     (5)    The date/time (in seconds since midnight 1/1/70) at which the
  351.         compilation of this compilation unit occurred.  This value
  352.         should be interpreted as an unsigned quantity because gcc
  353.         might be configured to generate a default value of 0xffffffff
  354.         in this field (in cases where it is desired to have object
  355.         files created at different times from identical source files
  356.         be byte-for-byte identical).  By default, these timestamps
  357.         are *not* generated by dwarfout.c (so that object files
  358.         compiled at different times will be byte-for-byte identical).
  359.         If you wish to enable this "timestamp" feature however, you
  360.         can simply place a #define for the symbol `DWARF_TIMESTAMPS'
  361.         in your target configuration file and then rebuild the GNU
  362.         compiler(s).
  363.  
  364. Note that the first string placed into the .debug_sfnames section for each
  365. compilation unit is the name of the directory in which compilation occurred.
  366. This string ends with a `/' (to help indicate that it is the pathname of a
  367. directory).  Thus, the second word of each specialized initial .debug_srcinfo
  368. entry for each compilation unit may be used as a pointer to the (string)
  369. name of the compilation directory, and that string may in turn be used to
  370. "absolutize" any relative pathnames which may appear later on in the
  371. .debug_sfnames section entries for the same compilation unit.
  372.  
  373. The fifth and last word of each specialized starting entry for a compilation
  374. unit in the .debug_srcinfo section may (depending upon your configuration)
  375. indicate the date/time of compilation, and this may be used (by a debugger)
  376. to determine if any of the source files which contributed code to this
  377. compilation unit are newer than the object code for the compilation unit
  378. itself.  If so, the debugger may wish to print an "out-of-date" warning
  379. about the compilation unit.
  380.  
  381. The .debug_srcinfo section associated with each compilation will also have
  382. a specialized terminating entry.  This terminating .debug_srcinfo section
  383. entry will consist of the following two 4-byte words of data:
  384.  
  385.     (1)    The offset, measured from the start of the .line section to
  386.         the beginning of the terminating entry for the .line section.
  387.  
  388.     (2)    A word containing the value 0xffffffff.
  389.  
  390. --------------------------------
  391.  
  392. In the current DWARF version 1 specification, no mechanism is specified by
  393. which information about macro definitions and un-definitions may be provided
  394. to the DWARF consumer.
  395.  
  396. The DWARF version 2 (draft) specification does specify such a mechanism.
  397. That specification was based on the GNU ("vendor specific extension")
  398. which provided some support for macro definitions and un-definitions,
  399. but the "official" DWARF version 2 (draft) specification mechanism for
  400. handling macros and the GNU implementation have diverged somewhat.  I
  401. plan to update the GNU implementation to conform to the "official"
  402. DWARF version 2 (draft) specification as soon as I get time to do that.
  403.  
  404. Note that in the GNU implementation, additional information about macro
  405. definitions and un-definitions is *only* provided when the -g3 level of
  406. debug-info production is selected.  (The default level is -g2 and the
  407. plain old -g option is considered to be identical to -g2.)
  408.  
  409. GCC records information about macro definitions and undefinitions primarily
  410. in a section called the .debug_macinfo section.  Normal entries in the
  411. .debug_macinfo section consist of the following three parts:
  412.  
  413.     (1)    A special "type" byte.
  414.  
  415.     (2)    A 3-byte line-number/filename-offset field.
  416.  
  417.     (3)    A NUL terminated string.
  418.  
  419. The interpretation of the second and third parts is dependent upon the
  420. value of the leading (type) byte.
  421.  
  422. The type byte may have one of four values depending upon the type of the
  423. .debug_macinfo entry which follows.  The 1-byte MACINFO type codes presently
  424. used, and their meanings are as follows:
  425.  
  426.     MACINFO_start        A base file or an include file starts here.
  427.     MACINFO_resume        The current base or include file ends here.
  428.     MACINFO_define          A #define directive occurs here.
  429.     MACINFO_undef           A #undef directive occur here.
  430.  
  431. (Note that the MACINFO_... codes mentioned here are simply symbolic names
  432. for constants which are defined in the GNU dwarf.h file.)
  433.  
  434. For MACINFO_define and MACINFO_undef entries, the second (3-byte) field
  435. contains the number of the source line (relative to the start of the current
  436. base source file or the current include files) when the #define or #undef
  437. directive appears.  For a MACINFO_define entry, the following string field
  438. contains the name of the macro which is defined, followed by its definition.
  439. Note that the definition is always separated from the name of the macro
  440. by at least one whitespace character.  For a MACINFO_undef entry, the
  441. string which follows the 3-byte line number field contains just the name
  442. of the macro which is being undef'ed.
  443.  
  444. For a MACINFO_start entry, the 3-byte field following the type byte contains
  445. the offset, relative to the start of the .debug_sfnames section for the
  446. current compilation unit, of a string which names the new source file which
  447. is beginning its inclusion at this point.  Following that 3-byte field,
  448. each MACINFO_start entry always contains a zero length NUL terminated
  449. string.
  450.  
  451. For a MACINFO_resume entry, the 3-byte field following the type byte contains
  452. the line number WITHIN THE INCLUDING FILE at which the inclusion of the
  453. current file (whose inclusion ends here) was initiated.  Following that
  454. 3-byte field, each MACINFO_resume entry always contains a zero length NUL
  455. terminated string.
  456.  
  457. Each set of .debug_macinfo entries for each compilation unit is terminated
  458. by a special .debug_macinfo entry consisting of a 4-byte zero value followed
  459. by a single NUL byte.
  460.  
  461. --------------------------------
  462.  
  463. In the current DWARF draft specification, no provision is made for providing
  464. a separate level of (limited) debugging information necessary to support
  465. tracebacks (only) through fully-debugged code (e.g. code in system libraries).
  466.  
  467. A proposal to define such a level was submitted (by me) to the UI/PLSIG.
  468. This proposal was rejected by the UI/PLSIG for inclusion into the DWARF
  469. version 1 specification for two reasons.  First, it was felt (by the PLSIG)
  470. that the issues involved in supporting a "traceback only" subset of DWARF
  471. were not well understood.  Second, and perhaps more importantly, the PLSIG
  472. is already having enough trouble agreeing on what it means to be "conformant"
  473. to the DWARF specification, and it was felt that trying to specify multiple
  474. different *levels* of conformance would only complicate our discussions of
  475. this already divisive issue.  Nonetheless, the GNU implementation of DWARF
  476. provides an abbreviated "traceback only" level of debug-info production for
  477. use with fully-debugged "system library" code.  This level should only be
  478. used for fully debugged system library code, and even then, it should only
  479. be used where there is a very strong need to conserve disk space.  This
  480. abbreviated level of debug-info production can be used by specifying the
  481. -g1 option on the compilation command line.
  482.  
  483. --------------------------------
  484.  
  485. As mentioned above, the GNU implementation of DWARF currently uses the DWARF
  486. version 2 (draft) approach for inline functions (and inlined instances
  487. thereof).  This is used in preference to the version 1 approach because
  488. (quite simply) the version 1 approach is highly brain-damaged and probably
  489. unworkable.
  490.  
  491. --------------------------------
  492.  
  493.  
  494. GNU DWARF Representation of GNU C Extensions to ANSI C
  495. ------------------------------------------------------
  496.  
  497. The file dwarfout.c has been designed and implemented so as to provide
  498. some reasonable DWARF representation for each and every declarative
  499. construct which is accepted by the GNU C compiler.  Since the GNU C
  500. compiler accepts a superset of ANSI C, this means that there are some
  501. cases in which the DWARF information produced by GCC must take some
  502. liberties in improvising DWARF representations for declarations which
  503. are only valid in (extended) GNU C.
  504.  
  505. In particular, GNU C provides at least three significant extensions to
  506. ANSI C when it comes to declarations.  These are (1) inline functions,
  507. and (2) dynamic arrays, and (3) incomplete enum types.  (See the GCC
  508. manual for more information on these GNU extensions to ANSI C.)  When
  509. used, these GNU C extensions are represented (in the generated DWARF
  510. output of GCC) in the most natural and intuitively obvious ways.
  511.  
  512. In the case of inline functions, the DWARF representation is exactly as
  513. called for in the DWARF version 2 (draft) specification for an identical
  514. function written in C++; i.e. we "reuse" the representation of inline
  515. functions which has been defined for C++ to support this GNU C extension.
  516.  
  517. In the case of dynamic arrays, we use the most obvious representational
  518. mechanism available; i.e. an array type in which the upper bound of
  519. some dimension (usually the first and only dimension) is a variable
  520. rather than a constant.  (See the DWARF version 1 specification for more
  521. details.)
  522.  
  523. In the case of incomplete enum types, such types are represented simply
  524. as TAG_enumeration_type DIEs which DO NOT contain either AT_byte_size
  525. attributes or AT_element_list attributes.
  526.  
  527. --------------------------------
  528.  
  529.  
  530. Future Directions
  531. -----------------
  532.  
  533. The codes, formats, and other paraphernalia necessary to provide proper
  534. support for symbolic debugging for the C++ language are still being worked
  535. on by the UI/PLSIG.  The vast majority of the additions to DWARF which will
  536. be needed to completely support C++ have already been hashed out and agreed
  537. upon, but a few small issues (e.g. anonymous unions, access declarations)
  538. are still being discussed.  Also, we in the PLSIG are still discussing
  539. whether or not we need to do anything special for C++ templates.  (At this
  540. time it is not yet clear whether we even need to do anything special for
  541. these.) 
  542.  
  543. Unfortunately, as mentioned above, there are quite a few problems in the
  544. g++ front end itself, and these are currently responsible for severly
  545. restricting the progress which can be made on adding DWARF support
  546. specifically for the g++ front-end.  Furthermore, Richard Stallman has
  547. expressed the view that C++ friendships might not be important enough to
  548. describe (in DWARF).  This view directly conflicts with both the DWARF
  549. version 1 and version 2 (draft) specifications, so until this small
  550. misunderstanding is cleared up, DWARF support for g++ is unlikely.
  551.  
  552. With regard to FORTRAN, the UI/PLSIG has defined what is believed to be a
  553. complete and sufficient set of codes and rules for adequately representing
  554. all of FORTRAN 77, and most of Fortran 90 in DWARF.  While some support for
  555. this has been implemented in dwarfout.c, further implementation and testing
  556. will have to await the arrival of the GNU Fortran front-end (which is
  557. currently in early alpha test as of this writing).
  558.  
  559. GNU DWARF support for other languages (i.e. Pascal and Modula) is a moot
  560. issue until there are GNU front-ends for these other languages.
  561.  
  562. GNU DWARF support for DWARF version 2 will probably not be attempted until
  563. such time as the version 2 specification is finalized.  (More work needs
  564. to be done on the version 2 specification to make the new "abbreviations"
  565. feature of version 2 more easily implementable.  Until then, it will be
  566. a royal pain the ass to implement version 2 "abbreviations".)  For the
  567. time being, version 2 features will be added (in a version 1 compatible
  568. manner) when and where these features seem necessary or extremely desirable.
  569.  
  570. As currently defined, DWARF only describes a (binary) language which can
  571. be used to communicate symbolic debugging information from a compiler
  572. through an assembler and a linker, to a debugger.  There is no clear
  573. specification of what processing should be (or must be) done by the
  574. assembler and/or the linker.  Fortunately, the role of the assembler
  575. is easily inferred (by anyone knowledgeable about assemblers) just by
  576. looking  at examples of assembly-level DWARF code.  Sadly though, the
  577. allowable (or required) processing steps performed by a linker are
  578. harder to infer and (perhaps) even harder to agree upon.  There are
  579. several forms of very useful `post-processing' steps which intelligent
  580. linkers *could* (in theory) perform on object files containing DWARF,
  581. but any and all such link-time transformations are currently both disallowed
  582. and unspecified.
  583.  
  584. In particular, possible link-time transformations of DWARF code which could
  585. provide significant benefits include (but are not limited to):
  586.  
  587.     Commonization of duplicate DIEs obtained from multiple input
  588.     (object) files.
  589.  
  590.     Cross-compilation type checking based upon DWARF type information
  591.     for objects and functions.
  592.  
  593.     Other possible `compacting' transformations designed to save disk
  594.     space and to reduce linker & debugger I/O activity.
  595.